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ABSTRACT 

The overall structure and capabilities of an expert system designed to evaluate rocket en- 
gine performance are described. The expert system incorporates a JANNAF standard refer- 
ence computer code to determine rocket engine performance and a state-of-the-art finite ele- 
ments computer code to calculate the interactions between propellant injection, energy re- 
lease in the combustion chamber, and regenerative cooling heat transfer. Rule-of-thumb 
heuristics have been incorporated for the hydrogen-oxygen coaxial injector design, including 
a minimum gap size constraint on the total number of injector elements. One-dimensional 
equilibrium chemistry was employed in the energy release analysis of the combustion cham- 
ber. A three-dimensional conduction/one-dimensional advection analysis is used to predict 
heat transfer and coolant channel wall temperature distributions, in addition to coolant tem- 
perature and pressure drop. Inputting values to describe the geometry and state properties of 
the entire system is done directly from the computer keyboard. Graphical display of all output 
results from the computer code analyses is facilitated by menu selection of up to five depen- 
dent variables per plot. 

INTRODUCTION 

The process of designing a rocket engine involves many complex domains of technical ex- 
pertise (figure 1). Each discipline has a unique set of computer codes, a unique set of past 
experimental experience, and a specific set of constraints which guide the component design 
process. Overall engine size and performance parameters are determined by an analyst who 
is concerned with the overall mission and vehicle. The injector is often selected using exist- 
ing experience based on past performance. Regenerative cooling channels and the thrust 
chamber design are also chosen for good historical performance reasons. Other areas of en- 
gine design include performance analysis of the expanding gases, design of a high performing 
expansion nozzle, predicting the atomization process of the chosen injector, and evaluating 
the combustion and injection processes for the possibility of combustion instability. 

Designing a rocket engine also requires the solution of many multidisciplinary issues. Ac- 
curate design of rocket engine components assumes that an open channel of communication 
exists between the resident experts in each of the knowledge domains, and relies upon an it- 
erative process to arrive at a solution. The injector designer needs to know the engine pa- 
rameters and the propellant injection temperatures to design the elements. To do his job, the 
chamber designer requires the propellant injection temperatures and chamber geometry data 
to calculate the heat transfer to the regenerative cooling channels. The amount of energy in- 
jected into the chamber, transferred through the chamber wall to the coolant, and then reintro- 
duced into the chamber is determined by successively using improved estimates as calculat- 
ed by the computer codes. 

The computer codes in use by the designer of each component have always been complex 
to run and to understand due to the necessity of modeling the physical phenomena as closely 
as possible. The task of running single-point designs, which are commonly derived by slight- 
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ly varying previously run cases, is far easier than developing input datasets for a design from 
scratch. Even after the computer program accepts the input data, the user must be careful in 
interpreting the results. 

As a result of the various necessary areas of expertise, the required interaction between 
these areas, and the complexity of each area’s computational tools, some less-than-rigorous 
approaches to rocket engine design have been established in each discipline. Hard-earned 
experiences have been condensed to simplified “rules-of-thumb,” the lack of open channels 
of communication between disciplines has resulted in “open-loop” approaches to engine de- 
sign, and computer codes which make a compromise between technical thoroughness and 
ease-of-use and understanding are relied upon to a great extent. 

To provide a rigorous solution to the problem of rocket engine design, the obstacles men- 
tioned above need to be eliminated. All disciplines must be represented, if not in a complete- 
ly thorough fashion, then by their “rules-of-thumb” which can be relied upon to provide engi- 
neering approximations to specific questions. Complex codes must give the engineer more 
than hard-to-read tables of output. They must have a user-interface which makes the codes 
easy to use, allows for the sharing of input data between more than one code, and provides 
the user easy-to-understand output information. The computer codes need to interact with 
each other, allowing for iteration towards a solution and design optimization. Finally, the 
codes need to be collected in a framework which allows for future growth of capability, up- 
grades of current functions, and inclusion of new computational modules. 

To meet all of these goal will require many years of programmer’s time and larger, faster 
computers, in addition to the continued evolution of the technical design codes. A method of 
providing the interface between user and computer program, and between more than one 
computer program, can be done through the use of an expert system shell. The Rocket En- 
gine Design Expert System (REDES) prototype is an initial attempt to achieve the goals for 
better rocket engine design through these means. As well as encouraging and insuring prop- 
er utilization of the rocket engine evaluation codes, the first stage of the expert system de- 
sign was to implement a method of collecting data from the user, sharing inputs and outputs 
between computer codes, and displaying the results. The expert system being designed is 
currently addressing the problems encountered in trying to keep track of the large amounts of 
data required to run the available evaluation codes. As the number of evaluation codes which 
are contained in the expert system grows, the amount of data required to run them will in- 
crease, also. The capabilities of REDES can be expanded to handle these new inputs in man- 
ageable steps and be used as a design tool at each stage of development. 

EXPERT SYSTEM OVERVIEW 

The approach taken was to construct the expert system within a shell in a modular fash- 
ion. Each part of the expert system was initially designed with a low level of complexity with 
the intention of increasing the complexity (and functionality) in an incremental fashion. For 
example, the initial analysis of the thrust chamber energy release is one dimensional equilib- 
rium (ODE) chemistry, but the ultimate development of this portion of the program would in- 
clude state-of-the-art finite-rate reaction models. This module accepted inputs from the sim- 
plified injector design module and provides outputs that are required as input to the three-di- 
mensional regenerative cooling channel module. Once the computational loop is functioning 
properly for these simplified modules, the complexity of any one of the modules can be in- 
creased without greatly interrupting the flow of information between them. Upgrading the 
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one-dimensional chemical reactions to include kinetic effects can be done later and only 
slightly affects the data flow between modules. Similarly, the complexity of existing modules 
can be increased or new modules can be added without having to make major changes to the 
fundamental structure of the expert system. Proceeding from the simple scheme to the more 
. complicated can be done after other capabilities become operational and the interaction be- 

tween parts is successfully demonstrated. In a similar manner, the functional complexity of 
the injector element design, injector face design, regenerative cooling channel evaluation, and 
* the analysis of other parts of the engine, can all be initially integrated and tested at a low lev- 

el of complexity. 

The first “closed-loop” computation consisted of the injector design-energy release-re- 
gen cooling computational iteration. Specific computer programs which were included in the 
expert system include the Three Dimensional Kinetics (TDK) code 1 , and the Rocket Thermal 
Evaluation (RTE) code 2 . Initial implementation of the TDK code only uses the ODE chemical 
reaction program contained in TDK as a subprogram. 

The expert system can accept input data describing a rocket engine, determine the re- 
quired number and size of coaxial elements for that engine, determine the energy release of 
the combusting propellants based on one dimensional equilibrium calculations, and calculate 
the heat transfer to a coolant flowing through the regenerative cooling channels of the en- 
gineusing a three-dimensional conduction code. 

The structure of the data which define thrust chambers, nozzles, and other components of 
a rocket engine was determined by input data requirements of the included computer codes. 
The information which is collected for each component is only that which is required for the 
computer programs which are currently available. Therefore, if pertinent data for component 
#1 is A, B, C, and D, but code XYZ only needs A, B, and C, the input of D may not be provid- 
ed for at the current time. In most cases, if the data is not needed, it is not asked for. Possi- 
ble values for injector and propellant types were limited to facilitate the expert system devel- 
opment. Injector design is limited to coaxial tube injectors and the only allowable types of fu- 
el and oxidizer are diatomic hydrogen and diatomic oxygen. 

The form of the user interface was created to provide ease of use and understanding 
(figure 2). It consists of an “Engine Control” table (or panel) of parameters, divided into 
groups (called subpanels , such as thrust chamber, injector, for example), and each group has 
entries (also called slots) in the table where values can be input as well as table entries 
where calculated output values are displayed. If a value is entered into an input slot which is 
connected to a computation, the output value affected by the input slot will be updated imme- 
diately. Some calculated values can be computed in many different ways. For example, the 
thrust chamber diameter can be computed from either the injector face area or the contraction 
ratio and the area of the throat. Only one method of calculation has been currently implement- 
ed in the expert system. The flexibility of being able to calculate all possible quantities given 
a limited set of inputs is currently being sacrificed to avoid infinite self-referencing calcula- 
tions. 

An input-output relationship exists between the user, the subpanels, and the computer 
f codes as shown in figure 3. The user provides inputs to the subpanels which compute output 

values in other subpanels or provide input values for the computer codes. Interaction with the 
program is through a menu selection or, in the case of numerical values, by dir ectly typing 
them in from the keyboard. The method of accessing data, creating datasets, executing a FOR- 
TRAN program, and extracting the desired output data was implemented in RED ES When a 
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FORTRAN computer program is to be run, computer programs (called methods), written in 
the computer language LISP, perform the functions of collecting the necessary data, create a 
well-formed input dataset for the FORTRAN code, run the code, and finally, look through the 
output for necessary information and then store that information in the expert system format. 
This process is initiated by pushing a button (called a method actuator). 

Computer codes ultimately provide the necessary data for conveying the computed infor- 
mation back to the user (figure 3) in the form of graphs. Display of the program results in 
graphical form was developed and extended to provide plots with multiple dependent vari- 
ables. Figure 4 displays the panel on which the graphs are constructed. Method actuators 
are used to plot nozzle contours or X-Y plots. Nozzle contours are specified in the nozzle 
subpanel located on the Engine Control panel. Abscissa parameters and up to five ordinate 
parameters are specified on the graphic panel via pop-up menu selection. The plotted param- 
eters can be from the same computer run or from two (or more) different runs. This allows 
comparative plots showing similar parameters from different engines or engine conditions. 

SUMMARY 

Designing a rocket engine requires the expertise of many disciplines which exist in both 
the analytical and empirical domains. Computer codes presently attack a portion of the entire 
problem at best, usually at the expense of user-friendliness or generality. 

A prototype of a rocket engine design expert system has been designed using an expert 
system shell to encourage and insure the proper use of a wide range of codes. The develop- 
ment of the expert system is incremental starting with simple physical models and systems 
and progressing toward completely detailed systems using transient, three-dimensional 
state-of-the-art models. Energy release in the combustion chamber is presently modeled us- 
ing ODE and the temperature distribution of the chamber wall is calculated with RTE. Current- 
ly, the injector design is limited to coaxial tube injectors using diatomic oxygen as the oxidiz- 
er and diatomic hydrogen as the fuel. 

The expert system uses panels and subpanels to control input and output. Values which 
describe the different pieces of the entire rocket engine are directly input from the keyboard. 
Calculating or nondimensionalizing nozzle coordinates and imposing a minimum coaxial gap 
size to determine the number of injector elements can be performed at the touch of a button. 
Output values are displayed graphically in user-specified plots with up to five dependent 
variables per plot. 

The ultimate goal of being able to optimize an engine design considering all of the contrib- 
uting, complex factors using a closed loop process is becoming a reality with the develop- 
ment of the Rocket Engine Design Expert System. 
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Figure 1. There are numerous technical disciplines which are involved in the design of a liquid rocket en- 
gine. Those which appear with an asterisk (*) are currently included in the Rocket Engine De- 
sign Expert System Prototype. 
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Figure 2. On-screen display of the Engine Control Panel. Visible portion of metapanel is dark gray column 
on the left and individual subpanels are to the right of each subpanel identifier display. 
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Figure 3. An input-output relationship exists between the user, the subpanels, and the computer 
codes. Subpanels and computer codes both provide output back to the user. 
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Figure 4. On-screen display of the entire Graphic Control Panel showing nozzle contour of Current Engine 
(ENGINE.ASE) and a specific impulse plot from an ODE evaluation of the Advanced Space En- 
gine. 
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